Nodes that implement this change will commit different values than those who do not. Namely, implementors may commit values where others may commit errors.

While this can be seen as a breaking change, strictly speaking, changes to witnessing behavior like this can't really jeopardize consensus or data integrity — provided that the affected data requests are already being tallied to an error.

That is to say that we should be fine releasing this without a TAPI guard because it will not make data requests start to fail but rather make them end up with a different error for as long as there's no majority of implementors in the witnessing committee, to eventually make it succeed with a value when the implementors are in majority.

What do you think @witnet/devs?

I think under the assumptions that you mention, it is fine to release this without TAPI.

As long as a change does not influence validation or consensus logic and whether someone implements this change or not (to use WIP terms) has no implications to network liveness and / or correctness, it does not require TAPI. This does brings up the question whether something like the redirect WIP was really necessary and probably requires updating the WIP rules or a stricter compliance to them.

I'm aiming at shipping this together with #2385 in an eventual 1.6.6 release.